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REMARKS 

In the patent application, claims 1-7, 9-17, 19-34 and 36 are pending. In the final office 
action, all pending claims are rejected. 

Applicant has amended claims 1-7, 9-17, 19-34 and 36. 

Claims 1,11,21 and 26 have been amended to include the limitation that the one 
parameter comprises a shift amount in time indicative of a difference between a sampling time 
and a transmission of a packet at the server. 

The support for the amendment can be found in claims 2 and 3. 

Claims 2, 12, 22 and 29 have been amended to include the limitation that the shift amount 
is substantially equal to the difference. 

The support for the amendment can be found in the original claim 2. 

Claims 3, 13, 23 and 30 have been amended to include the limitation that the shift amount 
is greater than the difference. 

The support for the amendment can be found in the original claim 3. 

Claims 6, 10, 16, 25 and 32 have been amended to include the limitation that the 
parameter comprises a shift amount indicative of a clock drift between the server and the client. 

The support for the amendment can be found on page 13, line 33 to page 14, line 4 of the 
specification. 

Claims 4, 5, 7, 9, 14, 15, 17, 19, 20, 24, 27, 28, 31, 33, 34 and 36 have been amended to 
change the wording of the claims. 

No new matter has been introduced. 

At section 2 of the office action, claims 1-7, 9-17 and 19-34 and 36 are rejected under 35 
U.S.C. 102(e) as being anticipated by Ravi et al (U.S. Patent No. 6,292,834, hereafter referred to 
as Ravi). 
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The Examiner states that Ravi teaches a method for multimedia streaming as claimed in 
claim 1 . 

It is respectfully submitted that claim 1 includes the limitations of 

1) defining in a client in a multimedia streaming network at least one parameter for 
determining a rate adaptation operating range, wherein the streaming network comprises a server 
configured for providing streaming data to the client, the client having a receiver buffer for 
storing at least part of the streaming data to compensate for a difference between data 
transmission amount by the server and usage amount of the streaming data by the client so as to 
allow the client to have sufficient amount of streaming data to play out in a non-disruptive 
manner, and wherein the rate adaption operating range is used for rate adaptation between the 
server and the client; 

2) providing to the server information indicative of said at least one parameter; 

3) adapting in the server the data amount to a reception rate at the client based on said at 
least one parameter, and 

4) adjusting in the client packet transfer delay variation based on said adapting, wherein 
the one parameter comprises a shift amount in time indicative of a difference between a sampling 
time and a transmission time of a packet at the server . 

In rejecting claim 1, the Examiner points to column 6, lines 33-47; column 7, lines 16-25 
and column 8, lines 26-45 to show that Ravi discloses adapting in the server the data amount to a 
reception rate at the client based on said at least one parameter. 

In rejecting claims 2 and 3, the Examiner further states that Ravi discloses a minimum 
shift amount (decrease bandwidth threshold 512, column 7, lines 35-45) and a target shift amount 
(delta playtime and shift amount, column 8, lines 36-65). 

Applicant respectfully disagrees. 

At column 6, lines 32 to 47, Ravi discloses: 

The present invention is directed at the efficient and reliable streaming of data packets 
from stream server 220 to client computer 240, accomplished by optimally utilizing the 
bandwidth of the connection provided by computer network 290 while minimizing the loss 
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of packets. In one embodiment, the transmission rate of the data stream is dynamically 
adjusted in response to changes in the bandwidth made available by computer network 
290 for the network connection between server 220 and client computer 240. 
Accordingly, server 220, in response to feedback from client computer 240, dynamically 
selects transmission rates in order to better match the varying bandwidth capacity of the 
network connection. For example, server 220 streams video packets at 1 frames/second 
(fps), 5 fps, 10 fps, and 15 fps for bandwidths of 4 kbits/second (kbps), 14 kbps, 18 kbps, 
and 44 kbps. 

In the above paragraph, Ravi only discloses that the transmission rate of the data stream is 
adjusted in response to the changes in the bandwidth made available of the computer network 
between the server and the client. For example, the streaming can be carried out at 1, 5, 10 and 
15 fps for bandwidths of 4, 14, 18 and 14 kps. 

At column 7, lines 16 to 25, Ravi discloses: 

FIGS. 5 A, 5B, 5C, 5D and 5E, are detailed flowcharts illustrating steps 410, 420, 430, 
440 and 450, respectively, of FIG. 4. In step 410, the performance variables are 
computed. Next, in step 420, the computed performance variables are used to determine 
if it is desirable to decrease the bandwidth, and if so, then in step 430, the bandwidth is 
decreased. If a bandwidth decrease is not desirable, then in step 440, the performance 
variables are used to determine if it is desirable to increase the bandwidth. If a 
bandwidth increase is desirable, then in step 450, the bandwidth is increased. 

In the above paragraph, Ravi discloses the client computer 240 computes the performance 
variable (step 410), including computing playtime and delta_playtime (step 513); decreasing the 
bandwidth (step 430) and sending a reduce_bandwidth message to the server (step 537); or 
increasing the bandwidth (step 450) and sending an increase_bandwidth message to the server 
(step 522). According to Ravi, the term "bandwidth" is synonymous to the "transmission rate" 
(column 6, line 63 to column 7, line 5). 
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At column 7, lines 35-45, Ravi discloses: 

FIGS. 6A and 6B are two halves of a flowchart illustrating the dynamic determination of 
the Upper INC _BW threshold and the DEC _BW threshold, step 512 in greater detail In 
step 612, the difference (Dl) between the Current _Time and the previous time the 
dynamic bandwidth selection method was invoked is computed. In step 614, the difference 
(D2) between the timestamp of the last data packet currently in playout buffer 366 and 
the timestamp of the last data packet in playout buffer 366 during the previous invocation 
of the Adjust ^Bandwidth procedure, is computed. In step 616, the difference (D3) 
between the number of bytes received by the previous invocation and the number of bytes 
currently received (by the current invocation) is computed. 

At column 8, lines 26 to 65, Ravi discloses: 

FIG. 7 A is a flowchart illustrating the computation of variables Playtime and 
Delta _Playtime, step 513, in greater detail In step 710, Playtime is set to the Due time of 
the last packet in playout buffer 366. The computation of the Duetime is described in 
greater detail in step 740 below. Client computer 240 determines the change in the 
Playout ^Buffer _Size (step 720). The Delta ^Playtime is set to the difference between the 
current Playtime and the Playtime at the previous invocation of the Adjust _Bandwidth 
procedure (step 730). Variables Playtime and Delta Playtime provide exemplary absolute 
and relative measures, respectively, of the Playout _Buffer_Size, the number of data 
packet(s) in playout buffer 366. 

FIG. 7B illustrate the determination of the Duetime of a data packet (step 710). First, the 
BaseJTS is set to the timestamp of the first packet received by client computer 240 (step 
712). The BaseJTime is set to the time when the first packet was received (step 716). The 
TS is set the timestamp of the data packet of interest (step 746). 

In the above paragraphs, Ravi only discloses how the client computer 240 computes the 
Playtime and Delta Playtime (step 513, Figures 5a and 7a) 
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At column 8, lines 50-64, Ravi discloses: 

As shown in FIG. 8, in step 514, client computer 240 determines if Round _TripJTime_Bit 
should or should not be set to High The boolean equation 810 used for the determination 

is: 

(Round _Trip_Time>C18) & (Round _TripJTime has increased over the last CI 9 samples) 
& (New sampling of Round _Trip_Time occurred since the previous Reduce JBandwidth 
message was sent to the server because the Round _Trip Time _Bit was set to High) 
Wherein CI 8 is 4 seconds, and CI 9 is 3 samples. 

In step 516 of FIG. 9 f a determination of whether LossrateBit should be set to High. 

In the above paragraphs, Ravi discloses the new sampling of round-trip time (column 8, 
line 58). Ravi does not disclose a sampling time of a packet at the server. Ravi does not disclose 
a difference between the sampling time and the transmission time of a packet at the server. 

Furthermore, decrease bandwidth threshold, as disclosed in Ravi, is set such that when 
the playtime or the number of data packets currently in the playout buffer drops below that 
threshold. When that happens, the client sends a DEC B W message to the server for decreasing 
the transmission rate (col. 3, lines 15-19). Ravi discloses sending the DEC_BW message based 
on the relationship between the playtime and the number of data packets in the playout buffer at 
the client. Ravi does not disclose sending a parameter comprising the shift amount in time which 
is equal to the difference between the sampling time and the transmission time of a packet. 

The delta playtime, as disclosed in Ravi, is equal to the difference between the current 
playtime and the playtime at the previous invocation of Adjust_Bandwidth Procedure (step 730). 
Delta_Playtime provide an exemplary relative measure of the Playout_Buffer Size and the 
number of data packets in the playout buffer 366 (col. 8, lines 32-38). Thus, Delta_Playtime is a 
measure of the size and the number of data packets in the client playout buffer. Ravi does not 
disclose sending a parameter indicative of a shift amount greater than the difference between the 
sampling time and the transmission time of a packet. 
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On page 6 of the office action, first paragraph, the Examiner also states that Ravi teaches 
that the server, in response to the feedback from the client computer 240, dynamically selects 
transmission rates (streaming rates) in order to better match the varying bandwidth capacity of 
the network connection. However, Ravi does not disclose that the transmission rate is adjusted 
based on the parameter sent by the client, wherein the parameter comprises a shift amount in 
time indicative of a difference between the sampling time and the transmission time of a packet. 

For the above reasons, Ravi fails to anticipate independent claim 1 . 

For the same reasons, Ravi also fails to anticipate independent claims 11,21 and 26. 

In rejecting claim 6, the Examiner states that Ravi discloses that the parameter comprises 
a clock shift amount (column 10, lines 20-32). 

At column 10, lines 20-32, Ravi discloses: 

Referring now to FIG, 5D, if a bandwidth decrease is not desirable (420n), then in step 
440, the performance variables are used to determine if it is desirable to increase the 
bandwidth. In this conservative approach, if the Playout Buffer Size exceeds the Upper 
INC _BW threshold and continues to stay above the Lower INC _BW threshold for the 
INC _BW wait period, then the bandwidth is increased. In other words, the bandwidth is 
increased only when there is a fairly high probability that the next higher bandwidth will 
be sustainable by computer network 290. Hence, the Lower _INC_BW threshold 
requirement reduces the probability of the selected bandwidth oscillating rapidly between 
two bandwidth points and possibly causing jitter. 

In the above paragraph, Ravi only discloses how to reduce the probability of the selected 
bandwidth oscillating rapidly between two bandwidth points by using a certain 
increase_bandwidth threshold. Ravi does not disclose that the client sends a parameter 
comprising a shift amount in time indicative of a clock drift between the server and the client. 

For the above reasons, Ravi fails to anticipate independent claim 6. 
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For the same reasons, Ravi fails to anticipate independent claim 32 and dependent claims 
16 and 25. 

As for claims 2-5, 7, 9, 10, 12-15, 17, 19, 20, 22-24, 27-31, 33, 34 and 36, they are 
dependent from claims 1, 1 1, 21, 26 and 32 and recite features not recited in claims 1, 1 1, 21, 26 
and 32. For reasons regarding claims 1, 1 1, 21, 26 and 32 above, Ravi also fails to anticipate 
claims 2-5, 7, 9, 10, 12-15, 17, 19, 20, 22-24, 27-31, 33, 34 and 36. 
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CONCLUSION 



Claims 1-7, 9-17, 19-34 and 36 are allowable. Early allowance of all pending claims is 
earnestly solicited. 



Date: April |£ 2009 

WARE, FRESSOLA, VAN DER SLUYS 
& ADOLPHSON LLP 
Bradford Green, Building 5 
755 Main Street, PO Box 224 
Monroe, CT 06468 
(203) 261-1234 



Respectfully submitted, 





Kenneth Q. Lao 
Registration No. 40,061 
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